스탬프 결합도
1. 개요
1. 개요
스탬프 결합도는 객체 지향 프로그래밍과 소프트웨어 설계에서 중요한 개념 중 하나로, 클래스 간의 관계가 얼마나 강하게 연결되어 있는지를 나타내는 결합도의 한 유형이다. 이는 특정 클래스가 다른 클래스의 내부 데이터 구조에 직접적으로 의존하는 상황을 의미하며, 모듈 간의 의존성을 측정하는 지표로 사용된다.
낮은 결합도와 높은 응집도를 유지하는 것은 좋은 소프트웨어 설계의 기본 원칙으로 여겨진다. 스탬프 결합도는 이 원칙에 비추어 볼 때 일반적으로 바람직하지 않은 높은 수준의 결합으로 분류된다. 한 클래스가 다른 클래스의 객체 전체를 통째로(즉, '스탬프'처럼) 전달받아 그 내부의 특정 필드나 데이터 멤버에 접근할 때 발생한다.
이러한 결합 형태는 정보 은닉 원칙을 위반할 가능성이 크다. 한 모듈이 다른 모듈의 내부 구현 세부사항을 알게 되면, 해당 구현이 변경될 때 의존하는 모듈도 함께 수정해야 할 위험이 생긴다. 결과적으로 시스템의 유지보수성이 저하되고 재사용성이 낮아질 수 있다.
스탬프 결합도를 완화하기 위한 일반적인 방법으로는 필요한 데이터만을 매개변수로 전달하거나, 인터페이스를 통해 추상화된 계약에만 의존하도록 설계를 변경하는 것이 있다. 이를 통해 결합도를 더 낮은 수준(예: 자료 결합도)으로 낮추고, 모듈의 독립성을 향상시킬 수 있다.
2. 정의
2. 정의
스탬프 결합도는 객체 지향 프로그래밍 설계에서 두 클래스 사이의 관계가 특정한 자료 구조나 복합 데이터 타입을 통해 이루어질 때 발생하는 결합 유형이다. 이는 한 클래스가 다른 클래스의 내부 객체 전체가 아닌, 특정한 구조체나 레코드 형태의 데이터 일부만 필요로 함에도 불구하고, 그 전체 구조에 의존하게 되는 상황을 가리킨다.
구체적으로, 한 모듈이 다른 모듈로부터 전달받은 복합 데이터의 내부 필드 중 일부만 사용하는 경우에도, 데이터의 전체 구조에 대한 지식이 필요해지므로 결합이 형성된다. 예를 들어, 고객 정보가 담긴 CustomerRecord라는 구조체를 매개변수로 받는 메서드가, 실제로는 그 안의 name 필드만 사용한다고 해도, 메서드는 CustomerRecord라는 자료형 자체에 결합되게 된다.
이러한 결합도는 일반적으로 중간 정도의 강도를 가진 것으로 평가된다. 이는 자료 결합도보다는 강한 연결이지만, 제어 결합도나 외부 결합도보다는 약한 연결에 해당한다. 소프트웨어 설계의 기본 원칙은 낮은 결합도와 높은 응집도를 유지하는 것이므로, 스탬프 결합도 역시 필요한 경우를 제외하고는 가능한 완화하는 것이 바람직하다.
3. 특징
3. 특징
스탬프 결합도는 모듈이나 클래스가 다른 모듈의 내부 데이터 구조를 직접 참조하거나 조작할 때 발생한다. 이는 특정 데이터 구조의 형태나 구성에 의존하게 되어, 해당 구조가 변경되면 이를 사용하는 모듈도 함께 수정해야 할 가능성이 높아진다. 예를 들어, 한 클래스가 다른 클래스의 인스턴스 변수에 직접 접근하거나, 복잡한 레코드나 객체 전체를 매개변수로 받아 그 중 일부 필드만 사용하는 경우가 여기에 해당한다.
이러한 결합도의 주요 특징은 의존성이 데이터의 '형태'나 '포맷'에 집중된다는 점이다. 모듈 간에 전달되는 데이터의 양이 많거나, 데이터 구조 자체가 복잡할수록 스탬프 결합도는 더 강해진다. 이는 정보 은닉 원칙을 위배하며, 시스템의 한 부분에서 발생한 변경이 예상치 못한 다른 부분으로까지 파급되는 리팩토링 비용을 증가시킨다.
따라서 객체 지향 설계에서는 스탬프 결합도를 가능한 낮추는 방향으로 설계하는 것이 권장된다. 구체적인 데이터 구조 대신 필요한 연산이나 행위를 객체의 인터페이스를 통해 제공하거나, 전달해야 하는 데이터의 범위를 최소화하는 매개변수 설계를 통해 결합도를 완화할 수 있다. 이는 궁극적으로 유지보수성을 높이고 시스템의 각 구성 요소를 보다 독립적으로 발전시킬 수 있도록 한다.
4. 장단점
4. 장단점
4.1. 장점
4.1. 장점
스탬프 결합도는 모듈 간의 상호작용이 필요한 데이터 전체를 전달하는 방식으로, 인터페이스를 통해 명확하게 데이터의 형태를 정의한다. 이는 자료 결합도보다는 결합 강도가 높지만, 제어 결합도나 공통 결합도에 비해 상대적으로 낮은 편에 속한다. 데이터의 구조가 명시적으로 드러나기 때문에, 한 모듈에서 다른 모듈로 전달되는 정보의 종류와 형태를 이해하기 쉽다는 장점이 있다.
이러한 결합도 수준은 시스템의 유지보수성을 향상시키는 데 기여한다. 데이터 구조가 변경되더라도, 그 구조를 사용하는 모든 모듈의 인터페이스를 함께 수정하면 되므로 변경의 영향 범위를 예측 가능하게 만든다. 또한, 객체 지향 프로그래밍에서 메서드 호출 시 객체나 구조체와 같은 복합 데이터 타입을 인자로 전달하는 패턴은 스탬프 결합도의 전형적인 예시이며, 이는 데이터를 캡슐화하여 전달함으로써 논리적 단위를 유지하는 데 도움을 준다.
따라서 스탬프 결합도는 지나치게 많은 데이터를 개별적으로 전달하여 결합도가 과도하게 낮아지는 것을 방지하면서도, 모듈 간의 의존성을 명확하고 관리 가능한 수준으로 유지하는 균형점을 제공한다고 볼 수 있다. 이는 소프트웨어 설계 원칙 중 하나인 '낮은 결합도'를 실현하는 실용적인 방법 중 하나로 평가받는다.
4.2. 단점
4.2. 단점
스탬프 결합도는 모듈이 다른 모듈의 내부 데이터 구조를 직접 조작하거나 그 구조에 의존할 때 발생한다. 이는 인터페이스를 통해 필요한 데이터만 주고받는 방식이 아니라, 복잡한 데이터 구조 자체를 통째로 전달하거나 참조함으로써 모듈 간의 연결을 강하게 만든다.
이러한 결합도의 주요 단점은 유지보수성을 크게 저해한다는 점이다. 한 모듈의 내부 데이터 구조가 변경되면, 이 구조를 사용하는 모든 다른 모듈들도 함께 수정해야 할 가능성이 높다. 이는 소프트웨어 개발 과정에서 변경 사항의 영향을 국소적으로 제한하기 어렵게 만들어, 시스템 전체의 변경 비용을 증가시킨다. 또한, 데이터 구조에 대한 지식이 여러 모듈에 분산되므로, 코드 가독성이 낮아지고 디버깅이 복잡해질 수 있다.
또 다른 단점은 재사용성이 낮다는 것이다. 특정 데이터 구조에 강하게 결합된 모듈은, 그 구조가 존재하지 않는 다른 컨텍스트나 프로젝트에서는 독립적으로 재사용하기 어렵다. 모듈의 기능 자체는 유용하더라도, 함께 딸려오는 데이터 구조에 대한 의존성 때문에 다른 곳에 적용하는 데 제약이 생긴다. 이는 객체 지향 설계의 중요한 목표 중 하나인 모듈화와 컴포넌트 재사용을 방해하는 요소가 된다.
마지막으로, 이 결합도는 캡슐화 원칙을 위반한다고 볼 수 있다. 객체의 내부 데이터는 외부에 최대한 숨겨져야 하지만, 스탬프 결합도는 모듈이 다른 객체의 내부 세부 사항을 알고 있어야 작동할 수 있도록 강제한다. 이는 정보 은닉을 저해하고, 시스템의 안정성을 떨어뜨리는 원인이 될 수 있다.
5. 사용 예시
5. 사용 예시
스탬프 결합도는 클래스나 모듈이 다른 모듈의 내부 데이터 구조를 직접 참조하거나 조작할 때 발생한다. 이는 객체 지향 프로그래밍에서 흔히 볼 수 있는 상황으로, 한 객체가 다른 객체의 인스턴스 변수나 필드에 직접 접근하여 데이터를 읽거나 변경하는 경우에 해당한다. 예를 들어, 고객 객체가 주문 객체의 내부 배열이나 리스트와 같은 복합 데이터 구조를 직접 조회하여 특정 항목을 계산하는 경우가 이에 해당한다.
구체적인 사용 예시를 들면, 쇼핑몰 시스템에서 Order(주문) 클래스가 Customer(고객) 클래스의 모든 주문 내역을 List<OrderItem> 형태로 가지고 있다고 가정하자. 이때 ShippingCalculator(배송비 계산기) 클래스가 배송비를 계산하기 위해 Customer 객체를 받아, 그 내부의 List<OrderItem>에 직접 접근하여 상품의 총 무게나 수량을 계산하는 방식이다. ShippingCalculator는 Customer 객체가 제공하는 공개 인터페이스(예: getTotalWeight() 메서드)를 사용하는 대신, 내부 데이터 구조(List<OrderItem>)를 직접 순회하며 필요한 값을 계산하게 된다.
이러한 접근 방식은 Customer 클래스의 내부 구현이 변경될 경우(예: List를 Map으로 변경하거나, 데이터 저장 방식을 바꾸는 경우) ShippingCalculator 클래스도 함께 수정해야 할 수 있다. ShippingCalculator는 Customer가 어떻게 주문 내역을 관리하는지에 대한 지식에 의존하게 되므로, 두 모듈 간의 결합이 강해진다. 이는 유지보수성을 저하시키고, 변경의 영향 범위를 넓히는 원인이 된다.
따라서 스탬프 결합도를 완화하기 위해서는, 데이터를 필요로 하는 모듈이 다른 모듈의 내부 구조를 직접 알지 못하도록 해야 한다. 위 예시에서는 Customer 클래스가 주문 항목의 총 무게를 계산하는 getTotalWeight() 같은 공개 메서드를 제공하고, ShippingCalculator는 이 메서드만 호출하도록 리팩토링하는 것이 바람직하다. 이렇게 하면 캡슐화 원칙을 준수하게 되어 결합도가 낮아지고, 응집도는 높아지는 효과를 얻을 수 있다.
6. 다른 결합도와의 비교
6. 다른 결합도와의 비교
스탬프 결합도는 다른 결합도 유형과 비교하여 그 특성을 명확히 이해할 수 있다. 결합도는 일반적으로 내용 결합도, 공통 결합도, 외부 결합도, 제어 결합도, 스탬프 결합도, 자료 결합도로 분류되며, 이 중 자료 결합도가 가장 바람직한 낮은 결합도에 해당한다.
스탬프 결합도는 자료 결합도보다는 결합 강도가 높은 편이다. 자료 결합도는 필요한 데이터만을 개별적인 매개변수로 전달하는 반면, 스탬프 결합도는 필요한 데이터 이상의 불필요한 정보를 포함한 복합 자료형 전체를 전달하기 때문이다. 이는 제어 결합도보다는 결합이 약한데, 제어 결합도는 한 모듈이 다른 모듈의 내부 논리 흐름을 제어하는 정보를 전달하기 때문에 더 강한 의존 관계를 형성한다.
따라서 결합도의 관점에서 보면, 스탬프 결합도는 자료 결합도와 제어 결합도의 중간 정도의 강도를 가진다. 설계 시에는 가능한 한 자료 결합도를 목표로 하되, 불가피한 경우 스탬프 결합도를 허용할 수 있으나, 그보다 강한 공통 결합도나 내용 결합도는 지양해야 한다. 이는 객체 지향 프로그래밍에서 낮은 결합도와 높은 응집도 원칙을 달성하는 데 중요한 기준이 된다.
